五金门店智能收银系统 AI 技术方案（完整版）

1. 项目背景与目标

传统五金门店在开单、进货、查账等环节操作繁琐，学习成本高。本方案通过多模态AI交互（语音/图片/表格/文本），实现自然语言直接驱动业务操作与数据分析，并将产品匹配与人工修正形成持续优化闭环，目标为：

门店操作效率提升 50% 以上；
新员工上手时间缩短至 1 天内；
产品匹配准确率在一次人工纠正后逐步提升至 95%+。

2. 总体架构

系统采用分层架构，核心分为：

接入层：支持语音、图片、Excel/PDF、文本四种输入。
意图分发层：统一将多模态输入转为标准JSON，并由意图大模型分流至三大处理链路。
业务处理层：通用问答（LLM直出）、Agent分析（查询+分析+生成）、常规操作（产品解析与匹配）。
数据与引擎层：Elasticsearch商品引擎（同步于MySQL）、离线数仓、日志采集。
自学习层：产品匹配模型的门店自适应学习、ES标签反哺。

核心技术选型：

语音识别：Qwen3-ASR-1.7B（本地化部署，支持噪声鲁棒增强）
大语言模型：Qwen3-72B/14B（可根据场景量化蒸馏）用于意图分类、产品解析、通用问答、Agent分析
向量模型：bge-large-zh-v1.5（商品语义向量化）
搜索引擎：Elasticsearch 8.x（支持向量检索）
数据同步：Canal + Kafka
模型微调框架：LoRA + Peft，适配门店个性化

3. 多模态输入与预处理

3.1 语音输入（重点优化）

3.1.1 引擎选择

使用 Qwen3-ASR-1.7B 端侧部署，该模型专为嘈杂环境优化，对五金店常见的切割声、搬运噪声具备更高鲁棒性。流式识别延迟控制在 500ms 以内。

3.1.2 领域增强策略

动态热词列表：维护门店级热词库（品牌：金杯、欧普；规格：2.5平、25w；口语词：一爪=一圈），通过ASR的上下文偏置（contextual biasing）提升专有名词识别率。
二次确认机制：识别结果若置信度低于阈值（如0.85）或包含模糊词（如"那个"），系统将结果渲染在麦克风悬浮窗，并用语音合成追问"您说的是'金杯2.5平电线5卷'吗？"，用户可语音确认/修正，形成交互闭环。

3.1.3 后处理纠错

结合本店商品列表构建一个轻量级的N-gram纠错模型或使用LLM（如Qwen3-1.7B）进行"识别结果→标准化文本"的映射，纠正如"金杯耳点武平"为"金杯2.5平"。

3.2 图片/PDF输入

文档分类：使用轻量视觉模型（MobileNetV3或CLIP变体）判断图片类型为"手写单据/商品标签/货架场景/证件"。
表格类（手写单/进货单）：通过OCR（PaddleOCR）提取文本，再用Table Transformer还原表格结构，最终由LLM根据表头语义合并为标准JSON。
非表格类：调用多模态大模型（Qwen-VL）直接提取关键信息："画面中金杯电线的规格是什么？数量多少？"
PDF处理：先用PyMuPDF拆页，是扫描件则走OCR流程，是电子文档则直接提取文字。

3.3 Excel/文本输入

Excel解析：不采用硬编码，将文件上传后由LLM（Code Interpreter模式）读取全部Sheet，自动识别表头、合并单元格，输出初步JSON，并标记不确定字段。前端展示映射界面，由用户简单拖拽确认，系统记住此次映射规则供后续复用。
文本输入：直接送入意图分类模块。

4. 意图识别与分发

意图分类模型

为避免多模型串联延迟，将意图分类与常规操作的初步解析合并为一个统一模型。在Qwen3-14B基础上进行指令微调（SFT），输入为："<多模态转写文本>"，输出为一个JSON：

{
  "intent_type": "general_qa" | "agent_analysis" | "operation",
  "permission_required": false,
  "confidence": 0.97,
  "operation_json": { ... }   // 仅在operation时出现初步解析结果
}

通用问答：直接路由至LLM模块，回答非业务类问题（天气、合同模板等），同时内置安全护栏，拒绝回答"删除数据库"等敏感指令。
Agent分析：需要查询历史数据、汇总统计。例如"汇总客户张三上个月对账单"。系统生成查询计划，通过离线数仓/只读副本执行，避免影响线上交易。
常规操作：开单、进货、折扣设置等。该意图下，operation_json 已由模型完成初步的产品字段提取，进入后续产品匹配流程。

歧义处理

当意图置信度介于 0.6~0.9 之间时，系统主动反问澄清，如："您是想查询销售记录，还是开一个新的销售单？"并将澄清结果作为上下文传入模型。

权限前置

在JSON中加入 required_role 字段（如"开单"需员工，"设置折扣"需店长）。前端根据当前登录角色拦截，必要时触发店长扫码授权。

5. 常规操作：产品解析与JSON生成

5.1 产品解析模型

采用与意图分类同一模型的不同输出分支，直接输出结构化商品列表：

"goods_list": [
  {
    "color": "红色",
    "spec": "2.5平",
    "model": "",
    "brand": "金杯",
    "product_name": "电线",
    "num": 5,
    "unit": "卷",
    "other": ""
  }
]

处理难点：

多候选拆分：对"金杯2.5平红蓝双色电线3卷"，模型同时输出两种候选：
A：单商品颜色=红蓝
B：两个商品，颜色=红色、蓝色各3卷
同时提供"原始字符串"字段，交给匹配引擎根据实际SKU存在性决定最终拆分。
"各种颜色"标记：不立即展开，保留 color: "ALL" 标记，并设置 all_color_flag: true，后续匹配时展示该供应商可供颜色列表供勾选。
单位归一化：维护一张门店同义词表（卷=圈=盘，只=个），在解析后做规则映射，统一为标准单位。

5.2 与前端协作

生成的JSON并非直接入库，而是渲染为可编辑的商品卡片列表。用户可点击单个商品修改任意字段，或通过拖拽调整数量。确认无误后点击"提交开单"。

6. AI数据匹配流程（核心）

6.1 名称完备性检查

拿到解析后的商品列表，检查必填属性是否齐全（五金行业通常品牌+品名+规格必填）。若缺失，匹配引擎从ES中提取该品类下所有可选属性值，组织成选择题，例如：

"您要的'电线'有以下规格：1.5平、2.5平、4平，请问是哪个？"

用户通过点选或语音回复完成补全。

6.2 多路召回与排序（混合检索）

在ES中建立商品索引，结构如下：

{
  "product_id": "P001",
  "store_id": "S01",
  "product_name": "电线",
  "brand": "金杯",
  "spec": "2.5平",
  "color": "红色",
  "model": "",
  "unit": "卷",
  "aliases": ["2.5平方电线", "红电线"],
  "vector": [0.023, -0.15, ...],  // bge编码
  "hot_score": 0.87,
  "store_hot_score": 0.92
}

三路召回：

规则召回：对品牌、规格做精确匹配（term query），对品名、别名做全文搜索（match）。得分=文本相关性。
语义召回：将用户query（品牌+品名+规格+颜色拼接）用bge模型向量化，进行knn检索，返回余弦相似度Top 50。
门店偏好召回：加权该门店近30天高频商品、当前操作员常开商品，形成优先队列。

混合排序（使用LightGBM训练LTR模型）：
特征包括：各路检索得分、商品历史销量、库存状态、门店偏好分、query与商品各属性的字符串匹配度等。输出综合排序Top5。

6.3 候选列表呈现与确认

前端弹出"请选择商品"浮层，展示Top5商品（主图、规格、库存、价格），并支持手动搜索其他商品。用户点击选择，商品自动填入开单卡片，完成匹配。

6.4 冷启动与长尾处理

新品或无点击商品主要依靠规则和语义召回。其语义向量由产品名称+属性拼接而成，初期可能不准。因此在界面保留"手动录入"入口，人工创建临时商品，系统在后台生成标准商品数据作为训练语料。

7. 自学习闭环

7.1 学习信号采集

记录每一次匹配的最终选择行为：

若用户直接点击推荐Top1 → 正样本。
若用户翻页选择第5个 → 微弱正样本。
若用户手动修改了推荐结果中的属性再确认 → 关键纠偏样本，记录修改前后字段对。
若用户完全手动创建新商品 → 将其query与新商品关联，作为新的别名对。

所有日志写入Kafka，经清洗后存入数据湖。

7.2 门店个性化模型（共享底层 + LoRA）

为了泛化又能隔离，产品匹配的语义模型采用如下架构：

基座模型：bge-large-zh，在全行业五金数据上微调（商品同义句对、别名对）。
门店适配层：每个门店拥有独立的LoRA权重（参数极少）。训练时只更新LoRA矩阵，输入为门店专属的纠正样本（query, 正样本商品向量, 负样本商品向量）。
推理时，根据 store_id 动态加载对应LoRA，使同一query在不同门店产生不同偏好排序（例如A店常卖金杯，B店常卖德力西）。

7.3 ES标签反哺

当人工纠正行为积累一定次数（如"电线"被手动加上"家装线"别名5次），触发脚本自动更新ES中该商品的 aliases 字段，增加"家装线"。下次规则召回即可命中。

7.4 防止错误累积

仅将店长确认的订单或同一用户/设备多次重复的纠正作为训练样本，避免个别员工误操作污染模型。
部署一个离线评估集，每次模型更新后自动回归测试，准确率下降则回滚。

8. Agent分析模块

用于处理需要多步推理和计算的任务，如"汇总供应商本四商贸上月对账单"、"分析本周滞销品"。

执行流程：

将用户问题转为分析计划（LLM生成SQL/ES查询语句）。
在只读从库或离线数仓执行查询，获取原始数据。
LLM对数据进行计算、对比，生成摘要和图表数据。
输出结果包含文字说明 + 可视化配置，前端渲染为报表。

主动建议：若分析出库存滞销，可自动生成"建议促销 9 折"的操作按钮，经用户确认后直接调用常规操作链路生成促销单。

9. 通用问答模块

直接使用通用LLM（如Qwen3-72B）返回答案，同时限制与本系统无关的敏感内容。通过system prompt设定角色为"五金店助手"，可安全回答天气、合同模板、薪资方案等非业务问题。

10. 前端交互设计要点

语音交互条：常驻底部，支持"点击说话"和"唤醒词"两种模式，识别过程中有波形动画，结果实时显示并可手动修改。
分步操作引导：当解析出多步复合指令（"向李四进货…同时把…打折"），前端以步骤条形式（步骤1：进货；步骤2：打折）引导用户一步步确认执行。
可编辑商品卡片：每张卡片包含商品字段、修改按钮、库存提示，确认无误后"一键开单/进货"。

11. 性能与工程架构

11.1 延迟优化

模型合并：意图分类与产品初步解析合为一个模型，减少一次网络调用。
语音本地化：Qwen3-ASR-1.7B部署在边缘端（店内服务器或高性能平板），无需上传云端，抗丢包且低延迟。
常用指令缓存：将高频指令（如"张三开单金杯2.5平红色电线5卷"）的ASR文本与解析结果存入Redis，命中后跳过推理直接返回结构化JSON。
ES预热：定时查询确保向量索引常驻内存。

11.2 数据同步

MySQL商品主表 → Canal监听binlog → Kafka → 实时同步服务写入ES。更新时保留旧版本，采用别名切换实现平滑更新。同步延迟监控小于1秒。

11.3 离线与在线分离

Agent的分析查询全部路由至只读副本或ClickHouse/Doris分析型数据库，OLTP和OLAP互不影响。

12. 安全与权限控制

接口鉴权：所有API需JWT token，并校验门店归属。
敏感操作二次确认：打折设置、删除单据等需弹出数字密码或店长扫码。
数据脱敏：对外展示的客户手机号等中间四位隐藏，内部Agent报表支持权限控制。

13. 多门店扩展与协同

基础商品库为总部统一维护，门店可创建私有商品（通过 store_id 隔离）。
产品匹配模型可跨门店检索共享库存，为"调拨建议"功能提供基础。
LoRA权重轻量，新门店开业时只需导入基础模型+少量标准微调样本，即可快速获得可用的门店模型，随后通过自学习逐渐个性化。

14. 实施路线图建议

MVP阶段：打通"语音→文本→意图分类→常规操作开单"主线，产品匹配采用简单规则+模糊搜索，不引入向量和自学习。
增强阶段：接入Qwen3-ASR和产品解析联合模型，上线多路召回+排序模型，开始采集纠正日志。
闭环阶段：启动LoRA个性化训练与ES别名自动更新，上线Agent分析（对账单、库存预警）。
扩展阶段：多门店调拨、主动建议、智能补货等。